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(54) Apparatus for accelerating navigation of hypertext pages using compound requests 



(57) A method for accelerating the navigation of hy- 
pertext pages based on a compound request is dis- 
closed. According to a request entered by a user, a 
choice card is received (902) In a client device and dis- 
played (904) as a list of items. One or more numerals 
are keyed into the device (906) and the request is ex- 
amined (908) to determine if the request is a compound 
request. If a single numeral is entered, the request is 
processed (918) as usual to fetch a card and then dis- 
play the card (914). If the entered request is a compound 
request, a parsing process Is activated (910) to parse 
the compound request Into individual requests. Then, a 
corresponding card is fetched (91 2) Individually for each 
Intermediate request without display of the intermediate 
card. When the final request is processed, the corre- 
sponding card containing desired infornnation is dis- 
played at (914). This compensates for the limited band- 
width of the current wireless data network and the low 
memory in mobile devices In use today. 
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Description 

BACKGROUND OF THE INVENTION 
Field of Invention 

[0001] This invention relates generally to data com- 
munications, and in particular to two-way data commu- 
nlcatbn devices, including a mobile computing device, 
a mobile device, a landttne telephone, and an Internet 
appliance controller, that permit a user to interface and 
interact with a server over a data network. 

Descriptbn of the Related Art 

[0002] The Internet is a rapidly growing communica- 
tion network of interconnected computers and computer 
networks around the world. Together, these millions of 
connected computers form a vast repository of hyper- 
linked informatk>n that is readily accessible by any of the 
connected computers from anywhere at any time. To 
provide mobility and portability, wireless Internet com- 
puting devices were introduced and are capable of com- 
municating, via wireless data networks, with the com- 
puters on the Internet. With the wireless data networks, 
people, as they travel or move about, are able to per- 
form, through the wireless computing devices, exactly 
the same tasks they could do with computers on the In- 
ternet. 

[0003] The most common remote access paradigm is, 
as of today, the one in which a laptop personal computer 
is equipped with a wireless communication mechanism 
such as a wireless modem. This paradigm may remain 
useful for a considerable number of mobile applications 
and users that are willing to tote a laptop personal com- 
puter. However, there has been a growing need for a 
mobile paradigm in which the Intemet can be instantly 
accessed by smaller mobile devices, such as mobile 
phones and personal digital assistants (PDA). The 
smaller mobile devices are generally designed very 
small in size and light in weight. With increasing data 
processing capabilities, more and more users are car- 
rying such devices around to materialize their unproduc- 
tive time into productive time. 

[0004] Regular mobile phones can retum calls, check 
voice mail or enable users to be available for telecon- 
ferences anywhere at any time. However, new mobile 
phones are desired that are not just reactive to calls but 
also are proactive. For example, an ideal mobile phone 
would meld voice, data, and PDA functionality into a sin- 
gle handset that can effectively, through a host compu- 
ter, access a myriad of public and enterprise information 
services in the Intemet. The evolution of the mobile 
phones or other mobile computing devices has been ev- 
idently fuelled by the demand of users for immediate ac- 
cess to the information they are looking for in the Inter- 
net. For example, a traveller may request the departure 
time of a next available flight when on the way to an 



airport, or a trader may purchase shares of stock at a 
certain price. The pertinent information from these re- 
quests or transactions may include the airline and the 
flight number for the traveller, as well as the stock name. 
s the number of shares and the price being purchased for 
the trader. To be timely and regularly informed, a pref- 
erable way is to electronically communicate the infor- 
mation requests using a wireless data network. The 
wireless data network, for example, connects to a flight 
10 information server or stock quote server so that the de- 
sired flight information or the current stock price can be 
retrieved therefrom on demand. 
[0005] To increase portability and mobility, most mo- 
bile devices are designed small in size, light in weight. 
15 low in power consumption, and as economical and port- 
able as possible. However, such mobile computing de- 
vices with such thin designs often have very limited com- 
puting resources. For example, the computing power of 
a mobile computing device may be equivalent to less 
than one percent of what is provided in a typical desktop 
or portable personal computer Furthermore, the mem- 
ory capacity of mobile computing devices are generally 
less than 250 kilobytes and their LCD display is perhaps 
four lines high by twelve or twenty characters and their 
graphics capabilities are very limited or nearly nonexist- 
ent. Finally, the input interface on mobile computing de- 
vices is often a keypad that has far fewer buttons than 
a PC keyboard does or a stylus and digitizer. These de- 
sign constraints generally seen in a mobile device make 
Internet navigation noticeably difficult. For example, it is 
quite labourious to enter a long alphanumeric Universal 
Resource Locator (URL) to access a specified service 
using the phone keypad. Nevertheless, there have been 
many efforts to provide efficient user input mechanisms 
through a phone keypad. For example, one common 
practice is to provide multifunction for the numerical 
keys in the phone keypad wherein each of the numerical 
keys or numbered buttons represents two or three let- 
ters in the English alphabets, such that a desired letter 
is obtained by repeatedly stroking a corresnonding nu- 
merical key. 

[0006] Another method is the use of a prediction 
mechanism based on the common usage of words to 
minimize keystrokes. For example, "e" may be automat- 
ically entered when a user keys in "th". A popular adopt- 
ed method in the Internet navigation in a mobile device 
is to provide a mechanism to predefine a set of URLs of 
frequently visited Web sites, each associated with a nu- 
meral. Therefore, merely pressing a specified numeral 
key leads to a corresponding Web site. However, many 
Web sites provide hierarchical layers or pages of infor- 
matton sen/ices, so that navigating through the hierar- 
chical Web site often demands further key stroking to 
reach a particular page through a number of intermedi- 
ate pages. Under the limited bandwidth of the current 
wireless data network and with the low memory in the 
mobile devices, the process of going via the intermedi- 
ate pages slows information transmission speed and in- 
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tensities the network traffic. Therefore, there Is a great 
need for an efficient mechanism that brings to the de- 
sired page without physically waiting for the delivery of 
every intermediate page In order to move onto the next 
page. There is a further need for a mechanism for thin s 
devices to reach a desired page without intensifying net- 
work traffic. When some Web sites provide hierarchical 
layers of information in different languages, navigating 
page by page to a desired page based on a hyperlink In 
intermediate pages can be difficult for users who may io 
only understand a particular language. There is thus still 
a further need for a way to a compound request to arrive 
at a desired page without following up all the intermedi- 
ate pages. 

IS 

SUMIViARY OF THE INVENTIOfM 

[0007] The present invention has been made in con- 
sideration of the above described problems and has par- 
ticular applications to the navigation of Internet web pag- 20 
es using thin devices, such as a mobile computing de- 
vice, a mobile device, a landline telephone, and an In- 
ternet appliance controller. Under the limited bandwidth 
of the current wireless data network and the low com- 
puting resources available in the thin devices, navigat- 2s 
ing hierarchical layers of accessible information based 
on a compound request yields unexpected results. The 
compound request generally comprises an antecedent 
request and a final request wherein the antecedent re- 
quest comprises a sequence of intemnediate requests. 30 
Users of the thin devices can now arrive at a desired 
page designated by the final request with only one com- 
pound request without having to follow up all intermedi- 
ate pages respectively designated by the intermediate 
requests. The Intermediate requests are parsed and 3S 
processed internally either in the thin devices or at a 
serwQT site, which increases significantly the delivery 
speed of the desired informatfon and reduces dramati- 
cally the network traffic. 

[0008] According to one embodiment, the present in- 40 
vention is a method for accelerating navigation of hier- 
archical layers of accessible Information hosted In a 
server device through a two-way Interactive communi- 
cation device over a data network, the method compris- 
ing: 45 

displaying a menu comprising a plurality of items, 
each having an address identifier; 
receiving a compound request entered by a user of 
the two-way Interactive communication device to so 
display desired information; 
parsing the compound request to obtain an ante- 
cedent request and a final request; 
processing the antecedent request and the final re- 
quest; and ss 
displaying the desired information. 

[0009] Accordingly, an important object of the present 



invention is to provide a method for accelerating navi- 
gation of hypertext pages in the Internet based upon a 
compound request from mobile devices. 
[0010] Other objects, together with the forgoing are 
attained in the exercise of the invention in the following 
description and resulting in the embodiment illustrated 
in the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWIMQR 

[0011] 

FIG. 1 illustrates one data network in which the 
present invention may be practised; 
FIG. 2 shows a block diagram of a typical digital mo- 
bile device that can be used in the data network of 
FIG. 1 to practice the present invention; 
FIG 3 depicts an architecture of a mobile device in 
communicatton with a server device over a cellular 
digital packet data (CDPD) network; 
FIG. 4A to 4G are illustrations of a series of screen 
displays of the mobile device in communication with 
the server device hosting an information web serv- 
ice; 

FIG. 5 illustrates tree structure of the information 
service provided by the web service hosted in the 
server device of FIG. 3; 

FIG. 6A to 6C display respective screen displays 
after receiving a compound request; 
FIG. 7 demonstrates internal card transitions within 
a deck; 

FIG. 8 depicts the process flow chart of the system 
of the disclosed invention; and 
FIG. 9 depicts an alternate process flowchart of the 
system of the disctosed invention. 

DETAILED DESCRIPTION OF THE INVENTION 

Notation and Nomenclature 

[0012] In the following detailed description of the 
present invention, numerous specif ic'details are set 
forth in order to provide a through understanding of the 
present invention. However, it will become obvious to 
those skilled in the art that the present invention may be 
practised without these specific details. In other instanc- 
es, well known methods, procedures, components, and 
circuitry have not been described in detail to avoid ob- 
scuring aspects of the present invention. 
[0013] The detailed description of the present inven- 
tion in the following are presented largely in terms of 
procedures, steps, logic blocks, processing, and other 
symbolic representations that resemble of data 
processing devices coupled to networks. These process 
descriptions and representations are the means used 
by those experienced or skilled In the art to most effec- 
tively convey the substance of their work to others 
skilled in the art. The present invention Is a method for 
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accelerating navigation of hypertext pages over a data 
network based on a compound request from a two-way 
communication device. The method to be described in 
detail below is a self-consistent sequence of processes 
or steps leading to a desired result. These steps or proc- 
esses are those requiring physical manipulations of 
physical quantities. Usually, though not necessarily, 
these quantities may take the form of electrical signals 
capable of being stored, transferred, combined, com- 
pared, displayed and otherwise manipulated in a com- 
puter system or electronic computing devices. It proves 
convenient at times, principally for reasons of common 
usage, to refer to these signals as bits, values, ele- 
ments, symbols, operations, messages, terms, num- 
bers, or the like. It should be borne in mind that all of 
these similar terms are to be associated with the appro- 
priate physical quantities and are merely convenient la- 
bels applied to these quantities. Unless specifically stat- 
ed otherwise as apparent from the following description, 
it is appreciated that throughout the present invention, 
discussions utilizing terms such as "processing" or 
■computing" or "verifying" or "displaying" or the like, re- 
fer to the actions and processes of a computing device 
that manipulates and transforms data represented as 
physical quantities within the computing device's regis- 
ters and memories Into other data similarly represented 
as physical quantities within the computing device or 
other electronic devices. 

The Preferred Embodiment 

[0014] Referring now to the drawings. In which like nu- 
merals refer to like parts throughout the several views. 
Figure 1 shows a schematic representation of a data 
network 1 00 in which the present invention may be prac- 
tised. The data network 100 comprises an airnet 102 
that is generally called wireless network and a landnet 
104 that is generally a landline network, each acting as 
a communication medium for data transmission there- 
through. The almet 102, In which the data transmission 
Is via electromagnetic radiation carried through the air- 
waves, is sometimes also referred to as a carrier net- 
work because each airnet is controlled and operated by 
a carrier such as AT&T or GTE. Each carrier may have 
its own communication scheme, such as CDPD and 
Code Division Multiple Access (CDMA), for the airnet 
102. The landnet 104 (sometimes referred to in this doc- 
ument as the Internet) may be the global Internet, an 
Intranet, or other public or private network. A two-way 
communication device 116. resembling a mobile device 
therein, can be a mobile computing device, a mobile de- 
vice, a cellular phone, a landline telephone, or an Inter- 
net appliance controller, capable of communicating with 
the airnet 102 via an antenna 108. It is generally under- 
stood that the airnet 102 simultaneously carriers the 
communication of a plurality of two-way communication 
devices, of which only one mobile device 106 is shown 
in Figure 1 . 



[0015] Similarly, connected to the Intemet 104 are a 
plurality of desktop personal computers (PCs) 110 and 
a plurality of server computers 112, though only one rep- 
resentative respectively shown in the figure. The PC 
5 1 1 0, as shown in the figure, may be a personal computer 
SPL 300 from NEC Technologies Inc. and runs a Hyper- 
Text Markup Language (HTML) or a Handheld Device 
Markup Language (HDML) Web browser. The browser 
access Information via the Internet 104 using HyperText 
Transfer Protocol (HTTP) or Handheld Device Transport 
Protocol (HDTP) to access information stored in the web 
server 112 that may be a workstatbn from Sun Micro- 
systems Inc. It is understood to those skilled in the art 
that the PC 110 can store accessible information therein 
so as to become a web server as well. Between the In- 
ternet 104 and the airnet 102 is a link server 114 that 
communicates data therebetween. The link sender 114, 
also referred to as proxy server or gateway, may be a 
workstation or a personal computer and performs map- 
ping or translation functkMis. For example, the link serv- 
er 114 may perform communicatk>n protocol mapping 
from one protocol to another, thus a mobile device 106 
can be in communication with any one of the servers 
112 or the PCs 110, respectively. 
[0016] One well-known communication protocol used 
by the Internet 104 is the Hypertext Transport Protocol 
(HTTP) that runs on the Transmission Control Protocol 
(TCP). HTTP is used to provide the connection of an 
HTML Web browser to a Web server and exchange in- 
formation therebetween. In one embodiment, the com- 
munication protocol between the mobile device 106 and 
the link server 11 4 via the airnet 102 is Handheld Device 
Transport Protocol (HDTP), or Secure Uplink Gateway 
Protocol (SUGP), which preferably runs on User Data- 
gram Protocol (UDP) and controls the connection of an 
HDML Web browser to a link server, where HDML 
stands for Handheld Device Markup Language. HDML, 
similar to that of HTML, is a tag based document lan- 
guage and comprises a set of commands or statements 
specified in a card that specifies how Information is dis- 
played on a small screen of the mobile device 106. Nor- 
mally a number of cards are grouped into a deck that is 
the smallest unit of HDML information that can be ex- 
changed between the mobile devbe 1 06 and the link 
server 114. More description on the HDML cards and 
deck will be described below wherever appropriate. The 
specifications of HDTP and HDML 2.0 Language Ref- 
erence are well known and readily available, their con- 
tent being incorporated herein by reference. 
[0017] The HDTP is a session-level protocol that re- 
sembles the HTTP but without incurring the overhead 
thereof and is highly optimized for use in thin devices 
that have significantly less computing power and mem- 
ory. Furthermore, it is understood to those skilled in the 
art that UDP does not require a connection to be estab- 
lished between a client and a server before infornnation 
can be exchanged as Is the case with TCP Thus, using 
UDP eliminates the need of exchanging a large number 



IS 



20 



25 



30 



3S 



40 



45 



SO 



7 



EP 0 938 052 A2 



8 



of packets during a session creation between a client 
and a server. Exchanging a very small number of pack- 
ets during a transactk^n is one of the desired features 
for a mobile device with very limited computing power 
and memory to effectively interact with a landline device. 

[0018] The link server 114, as the name suggests, 
links the aimet 102 to the landnet 104. Nevertheless, it 
can be appreciated that the link server 1 1 4 can function 
as a web server as well, providing information service 
directly to the nnobile devices that are in communicati<»i 
with the link sen/er 114 using HDTR Being coupled to 
the landnet 104 using HTTP, the link server 114 can fur- 
ther provide infonmatlon service to the PCs 100 or the 
workstations 112 and equally fetch information there- 
from. Therefore in the following description, the link 
server or a web server is indistinguishably used to mean 
a sen/er device that primarily provides informatton serv- 
ice to one or more mobile devices. 
[0019] Figure 2 illustrates a block diagram of a typical 
digital mobile phone 120 that can be used in the ar- 
rangement of Figure 1 to practice the present invention. 
Each of the hardware components in the mobile phone 
120 is known to those skilled in the art and so the hard- 
ware components are not described in detail herein. 
With the screen 116 and the keypad 118, a user of the 
phone 120 can interactively communicate with a server 
device (not shown in Figure 2) over a wireless data net- 
work. 

[0020] According to one embodiment, compiled and 
linked processes of the present Invention are stored in 
ROM 1 22 as a client module 1 24 and a support module 
126. Upon activation of a predetermined key sequence 
utilizing the keypad 118, a physical layer processor or 
microcontroller 1 26 initiates a communication session 
request to the server device using the module 1 24 in the 
ROM 122. Upon establishing the communication ses- 
sion, the phone 120 typically receives a single HDML 
deck from the server device and stores the deck as 
cached in RAM 1 34. An HDML deck or deck is the small- 
est unit of HDML information that can be exchanged be- 
tween a thin client device and a server device. Each 
deck has a unique address identifier such as a URL and 
includes one or more cards. A card includes the infor- 
mation required to generate a screen display on the dis- 
play screen 116. Thus, a deck Is simply a group of 
screen displays. The number of cards in a card deck is 
selected to facilitate efficient use of the resources In the 
mobile device and in the airnet network. A display driver 
1 30 receives and interprets information from the deck 
in the RAM and causes the screen 116 to display the 
information accordingly. The keypad driver 1 32 receives 
signals representing what buttons or keys in the keypad 
are depressed and converts the signals to a represen- 
tation understood by the microcontroller 1 28. The mi- 
crocontroller 1 28 may respond by activating a respec- 
tive card in the deck or accessing new deck by request- 
ing the server for a new deck if necessary depending on 



what choice is made through the phone keypad 118. 
[0021] The phone keypad 118 comprises, preferably, 
a typical phone keypad and a pair of generto buttons 
and at least a pair of upward and downward arrow but- 

5 tons. The typical phone keypad, as commonly seen, 
comprises twelve buttons. Of the twelve buttons, ten 
buttons are consecutively numbered, each for one of the 
numerals 0 to 9, respectively, one button is for sign 
and the other button is for sign. The four extended 

10 buttons, the generic and the arrow buttons, although not 
necessary in practising the present invention, provkJe 
convenient means for a user to interact with the phone 
120. 

[0022] Figure 3 shows the architecture of a mobile de- 

is vice 1 42 in communication with a server device 1 44 over 
a data network 140. The mobile device 1 42 is a two-way 
communication device that may be the digital phone 1 20 
of Figure 2. a mobile computing device, a landline tele- 
phone and an Internet appliance controller In Figure 3 

20 varbus components in one embodiment of this inven- 
tion of the mobile device 142 are shown. Those skilled 
in the art will appreciate that the mobile device 142 in- 
cludes circuitry and software similar to that illustrated in 
the mobile device 120 for voice and data operations. 

25 Similarly, the server device 1 44 includes other process- 
es and hardware that are known to those skilled in the 
art and are not illustrated in detail in the figure for clarity. 
[0023] In this embodiment, the client module 146 in 
the mobile device 1 42 communicates with the server de- 

30 vice 144 over a mobile digital packet data (CDPD) net- 
work 140. The mobile digital packet data network 140 is 
used to illustrate one embodiment of this invention on 
one two-way data communication network. The princi- 
ples of this invention can be used with a wide variety of 

35 two-way data communication networks. For example 
other two-way data communication networks for mobile 
telephones that may be used include TDMA. CDMA, 
and GSM circuit switched data networks; and the AMPS 
analog mobile network with a modem. Prior to consid- 

40 ering the operation of this configuration in Figure 3 in 
more detail, a technique for conveying instructions from 
the mobile device 142 to a server application on the 
server device 1 44 or vice versa is necessarily to be de- 
scribed herein. 

45 [0024] After a predefined key in the keypad 162 is 
pressed, the keypad nKxiule 1 70 causes the client mod- 
ule 168 to send a request to establish a connection, via 
the UDP interface 160, with server device 144. The re- 
quest generally comprises a URL identifying the server 

50 with which the client module 168 intends to exchange 
pertinent information. The server can be the server de- 
vice 1 44 or any computers on the Internet. The following 
descriptk^n is based on the assumption that the intended 
server is the sender device 144. Those skilled in the art 

55 will understand that the description is equally applied 
when the intended server is other than the server device 
144. 

[0025] As described before, information or instruc- 
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tions are grouped into one or nnore HDML cards required 
to generate a screen display. A deck includes one or 
more such cards. Additional information about cards 
and decks can be found in the specifk^ation of HDML 
Language Reference, Versk>n 2.0 mentioned above. As 
used herein, a screen display is the contents presented 
on the display screen that is the physical display appa- 
ratus such as a 4 lines by 20 characters LCD screen. 
For simplicity, in this embodiment, each deck is a single 
operation wherein an operation is defined as a related 
set of actions such that the user does not encounter an 
unanticipated delay in moving from one actbn t the next, 
i.e. the user does not have to wait for client module 146 
to retrieve another deck from the sen/er device 144. Fur- 
ther, a card may include definitions of soft keys that stay 
in force while the card is active, i.e., commands are rep- 
resented by the soft keys can be executed by the mobile 
device microcontroller, preferably through a pair of ge- 
neric buttons in the extended phone keypad. To provide 
information service to mobile devices, the server device 
1 44 stores a plurality of decks 1 54 containing accessible 
information. The server device 144 further generates 
HDML decks along with CGI program 158, in response 
to data from or choices made by the user of the mobile 
device 142. 

[0026] According to one embodiment of the present 
invention, the server device 1 44 fetches corresponding 
decks from stored HDML decks 1 54 in response to the 
request from the mobile device 142. The server nruxiule 
172 then transforms or compresses the correspond 
decks to a compiled version of HDML referred to as 
HDMLC, formerly known as terminal interaction lan- 
guage (TIL). HDML was formerly known as phone inter- 
action description language (PIDL). Through the use of 
the UDP interface 1 52. the server module 1 72 sends the 
compiled HDML decks or HDMLC decks to the nnobile 
device 142 using HTTP. HDML cards, like HTML files, 
are readable by humans while HDMLC cards are binary 
data and much smaller in terms of file size, applicable 
for transmission via a wireless network 140. Further- 
more, HDMLC cards allow easy parsing in the mobile 
device 142 environment. 

[0027] The compression from HDML cards or decks 
to HDMLC is done typically at run time, namely only the 
selected HDML cards are compressed when they are to 
be sent to the mobile device 1 42. It is known, however, 
that there are a wide variety of techniques that can be 
used to convert HDML cards or decks to a compressed 
version. For example, the verbs in the PIDL language 
are compressed using a binary tokenization. graphics 
are compressed using run length encoding compres- 
sion, and text is compressed using any one of the well- 
known techniques for text compression. The important 
aspect is that , if bandwidth across the wireless networit 
1 40 is limited, a compressed form of the selected HDML 
cards or decks is preferably used. In addition, a each 
data type, preferably is compressed to facilitate optimal 
transfer over the network 140. Nevertheless, it should 



be understood that the compression of HDML cards or 
decks is not required to implement this invention, com- 
pression makes the invention more efficient by utilizing 
the bandwidth of the network more effectively. 
5 [0028] The server device 144 uses UDP interface 
nrxxfule 152 to send data to and receive data from the 
CDPD network 1 40. HDML decks 1 54 are the decks that 
can be accessed by the HTTP module 156. It should be 
noted that the decks are accessible by the HTTP module 
1 56 using HTTP when the decks are physically loaded 
in another server on the Internet to which the server de- 
vice 144 is coupled. In this case, the selected HDML 
cards or decks are fetched to the HTTP module 1 56 and 
then compressed by the sen/er module 172 that subse- 
quently sends the compressed version, namely HDM- 
LC. to the mobile device 142. 

[0029] As indicated above, each interaction with the 
user of the mobile device 1 42 is described by a deck or 
a series of decks. Logically, the user retrieves an HDML 
deck stored in the memory 1 48 of the mobile device 1 42 
after receipt from the server devk^e 1 44 over the CDPD 
network 140. The user reviews the information dis- 
played by cards in the deck and makes choices and/or 
enters requested information and then requests another 
deck. 

[0030] A "deck" is the smallest unit of HDML informa- 
tion that can be exchanged with the server device. Each 
deck has a unique address identifier such as a URL. A 
user may navigate from one deck to another by travers- 
ing hyperiinks that reference a desired deck. According 
to one embodiment, the received deck or decks are nor- 
mally kept in the work memory 1 48 of the phone 1 42 in 
Figure 3. Upon receiving a request from the user, the 
client module in the mobile device 142 first consults the 
work memory 146 therein to determine if the requested 
deck is available. If the received request is met by one 
the cards in the received deck, the deck or the corre- 
sponding card in the deck Is accessed without requiring 
any communication with the server device. If the re- 
ceived request can not be satisfied by one of the cards 
in the received deck, which means the request has to 
be satisfied in a new deck, a connection initiated by the 
client module 146 to the server device 144 is made to 
fetch the new deck. Figures 4A through 4Q show the 
processing of the navigation requests, fetching request- 
ed information from a corresponding web service server 
and forwarding the information subsequently to the 
phone 142. This is discussed in more detail below. 
[0031] Regarding the cards used in the embodiment, 
there are four types of cards, an entry card, a display 
card, a choice card, and a no-display card. Regardless 
of the types, a card can contain text and images. In ad- 
dition, the invention is not limited to these particular 
types of cards. The definition of the particular types of 
cards is used to facilitate a description of the invention 
and to assist developers in organizing applications. To 
be more specific, a display card gives information to dis- 
play to the user. The displayed content can include any 



IS 



20 



2S 



30 



35 



40 



45 



SO 



6 



11 



EP 0 938 052 A2 



12 



one of. or any combination of text, an Image, and one 
or more soft keys. A choice card displays a list of choices 
for the user. The choices are automatically presented in 
a format specified on the choice card and generally 
numbered accordingly. As explained above, the user 
makes a choice by depressing a key corresponding to 
the choice. An entry card is used to obtain Input data 
from the user. An entry card displays one or more entry 
lines. Typically, each entry line includes a display fol- 
lowed by an entry line. The entry line, in this emlxxdi- 
ment, can be for either numeric or text data. A no-display 
card is a hidden card not for the purpose of being dis- 
played. The no<fisplay card is normally used to execute 
an intemnediate action and generally not known to a us- 
er. 

[0032] In this embodiment, choice and entry cards 
prevent the user from moving to the next card until the 
user has entered the requested information. When the 
user reaches the last card in a deck and hits a corre- 
sponding soft key, a request for a new deck is initiated. 
The deck requested is determined by either the deck 
that the user has completed, or by the choices made by 
the user. When the deck Is completed, the choices and/ 
or data entered by the user are typically transmitted 
along with the request to a server device for a new deck. 
When a deck containing multiple cards is received and 
stored in the cache memory, the client module In the 
phone fetches the first card in the deck and displays the 
information in the card on the screen of the phone and 
allows the user to respond thereto. Depending on the 
card type, the user responds by entering text or choos- 
ing an option, and then pressing a predetermined key 
to transact the response. 

[0033] Upon establishing a communication session 
between the mobile device 142 and the server device 
144, an initial deck transmitted to the mobile device 1 42 
includes an introductory display card and a choice card. 
Figure 4A is an example of introductory screen display 
302 that is generated on a display screen 300 by the 
client module In mobile device 142 by interpreting the 
display card. In this embodiment, the display screen 300 
is a pixel display that displays a graphic image. In an- 
other embodiment, display screen 300 displays only text 
and so the graphics would not appear on display screen 
300. Screen display 302, and other screen displays de- 
scribed more completely below, Include a horizontal ar- 
row 304, I.e., a multi-card deck indicator, to communi- 
cate to the user that the current deck includes another 
card. The Inclusion of screen Indicators, such as the 
multi-card deck indicator, to communicate with the user 
is optional. The functionality of this invention is inde- 
pendent of such screen indicators. Referenced by 306 
is a soft key generally associated with one of the generic 
buttons In the keypad of the mobile device 142. The soft 
key provides a mechanism to map the generic button 
into a specified button, namely to press the generic but- 
ton is equivalent to press an 'OK" button when the soft 
key OK is displayed. Again, the functionality of this in- 



vention is independent of such soft keys. 
[0034] When the user depresses a predetermined 
key, i.e. one of the generic buttons in this case, with re- 
spect to the soft key. the client module 1 46 In the mobile 
5 device 1 42 interprets the next card in the card deck and 
in turn generates a menu 308, as shown in Figure 4B. 
including a number of items that can be accessed by the 
user. A multi-display screen card indicator 312, e.g., in 
this embodiment, a downward arrow, shows that the 
10 screen display associated with the current choice card 
includes additional items that are not shown on display 
screen 300. Herein, a screen display can be larger than 
the number of lines available on the display screen 300 
and so the user must scroll the screen display to view 
^5 the complete screen. Thus, to view the additional items, 
the user presses the downward arrow key correspond- 
ing to the multi-display screen card indicator 312 on the 
display screen 300. In this embodiment, when the down- 
ward arrow key is pressed, each line of the display is 
rolled up one line. The resulting display has an icon with 
an upward arrow (not shown) if the menu requires only 
two screen displays. If the menu requires more than two 
screen displays, the second screen display of the menu 
would have two Icons, one with the upward arrow and 
another with the downward arrow. To scroll between the 
various lines in the second menu, the user uses the 
downward arrow key, and the upward arrow key. If the 
user displays the last line of a card, e.g., the last line in 
the second menu, and presses the downward arrow key 
nothing would happen because the downward arrow, 
icon, another soft key, will not be present. In this embod- 
iment, the user must make a choice before the next card 
is available. 

[0035] In this embodiment, each of the menu items is 
available on the server device 1 44 or distributed on sev- 
eral server computers In a data network. As explained 
more completely below, each of the menu items is as- 
sociated with a numeral that corresponds to a resource 
locator In the card containing the menu items. The re- 
source locator includes an address of the particular ob- 
ject associated with that menu Item. In general, a re- 
source locator includes a URL and may include append- 
ed data. The address can be to another card in the deck 
stored in the cache or to a remote object on a sender 
computer. As shown in Figure 4B, the first item in the 
menu 308 Is Initially indicated by an arrow 310 as a pre- 
chosen Item. If the user decides to proceed with the pre- 
chosen item, the soft key 'OK" may be pressed, or sim- 
ply press a numbered button "1 i.e. one of the 1 0 num- 
bered buttons, to cause the client module 146 in the 
phone 142 to activate and interpret a card specified by 
the address associated with the item. If the pre-chosen 
item is not a wanted one, the user may scroll the choice 
arrow 310 downward. It should be noted that scrolling 
to a selected item is a feature that is specific to this ex- 
ample, and in general is not required to implement the 
invention. Other methods can be used to indicate the 
user's choice on display screen 300 such as a horizontal 
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highlighting strip overshadowing the choice, if such an 
indication is desired. As described above, the user may 
simply key in one or nriore numerals to select an item 
that is of interest. 

[0036] As shown in Figure 4C. the user moves the ar- 
row 310 downward to the second item. After a predeter- 
mined button is pressed, i.e. either the soft key OK or 
the numbered button '2' is pressed, the resource locator 
for the selection is transmitted to the server device 
144by the client module in mobile device 142 over the 
data capable mobile telephone network 140. In re- 
sponse to the selection, the server device 144 process- 
es the request containing the selection, and in this em- 
bodiment, transmits another card deck to the mobile de- 
vice 144. In Figure AC, the display screen 316 shows 
four menu items numbered consecutively. As described 
above, the showing of the downward arrow Indicates 
that there are more items in the next screen. Each ot the 
items has its own address or URL, for example, for the 
first four items, the respective addresses may be: 

http ://www. abc. com 
http ://www. xyz info, com 
http://www.financialinfo.com 
http://www. personalweb.com 

When the second item is chosen, http://www.xyzlnfo. 
com is equivalently chosen. The client module 146 in 
the mobile device 142 establishes a connection to the 
sender that hosts the web site addressed by http://www. 
xyzinfo.com. The server sends a new deck to the phone 
100. The client module in mobile device 142 interprets 
the first card in the received deck from the server device 
144, which is a choice card, and generates a screen dis- 
play 316, that includes a second menu in a screen dis- 
play 316 lndk:ated by the downward arrow 312 as illus- 
trated in Figure 4C. As described above, the newly re- 
ceived deck is preferably stored in the cache memory, 
thus the subsequent navigatk>n takes place within the 
deck. 

[0037] As described above, the screen display 31 6 al- 
so includes the representations of two soft keys, an OK 
key 306, and a Back key 31 4. In this example, these soft 
keys are defined only for the card used to generate 
screen display 31 6. The 'OK' key allows the user to pro- 
ceed with the chosen item and the 'Back" soft key allows 
the user to go back the previous card if so desired. Other 
keys can be implemented, for example a "Home" key to 
allow the user to go back to the first page 308. The 
"Home" key is associated with a pointer, that in one em- 
bodiment is a resource locator, and the card addressed 
by the pointer is displayed by the client module when 
the 'Home' key is selected by the user. Specifically, if 
the pointer is to a card in the current deck, the client 
module simply displays that card, if the pointer is to other 
than a card in the current deck, the client module in mo- 
bile device 1 42 retrieves the deck containing the card at 
the location identified by the pointer. The location could 



be, for example, either a menrrary in the mobile device 
142, or a memory in the server device 144. 
[0038] In this example, the second item corresponds 
to an informatk>n Web site that is named "XYZ informa- 

5 tlon'. The Web site is configured to have a downward 
tree structure 400 of Information services as shown in 
Figure 5 in which the entry 402 must be passed through 
in order to access pertinent information in the tree struc- 
ture 400. Generally the tree structured information is 

10 hosted in a server device maintained and updated by a 
service provider and the entry 402 is designated by an 
address identifier, such as a URL expressed in the form 
of http://www.xyzinformation.com. According to the 
present example, the entry 402 contains a number of 

IS hyperlinkable nodes linking to other text pages that fur- 
ther contains a number hyperlinkable nodes. Like tree 
branches, the structure 400 ends with leaves that are 
text pages or display cards. It is understood to those 
skilled in the art that each hyperlinkable node has its 

20 own address. For example, a node "Weather" 406 under 
its parent node "Local News" may have the address: 

www.xvzinfo.com/LocalNews/Weather 
One of the final leaves along the node "Weather" 
25 406 is a page 420 that provides weather information 
in Town A and also addressed as 
h tt p : //www, xvz inf o . oom/Loca I N e ws/Weathe r/ 
ATown/data 

30 [0039] According to the tree structure 400, a path 
along the nodes "2" 402, "2" 404. '3' 406 and '1' 420, 
i.e. '2231", will lead to the page that contains weather 
information in Town A If it is what is interested in. To pass 
through the first node "2" 402 is equivalent to a first re- 

35 quest made in Figure AC, the subsequent node passage 
through "2" and '3* are conskilered as intermediate re- 
quests that have to be navigated in order to satisfy the 
last or final request of "1 ". 

[0040] Retuming to the screen display 318 in Figure 

40 4E which is another choice card that allows a user to 
further choose among a number of items, the downward 
arrow 312 indicates that it is a multi-screen card and 
there are more items that can be displayed if the down- 
ward arrow button is depressed. According to Figure 4E, 

45 a user selects the third item "Weather", the client module 
in the phone 1 00 Interprets the selection and displays a 
corresponding card that is designated by the third item 
in the figure. Figure 4F shows a display screen 320 from 
the corresponding card that again is a choice card with 

60 three items, hence there is no downward arrow sign is 
shown therein. The weather page provides weather in- 
formation of three different towns, Town A, Town 8 and 
Town C. If the user is interested in the weather informa- 
tion in Town A. the first rtem is indicated by the choice 

55 indicator 310 in the screen display 320. The process in 
the phone 1 42 interprets the selection from the user and 
returns a card that is a display card, resulting in a screen 
display 322. thereby the weather information in the dis- 
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play card is displayed. 

[0041] The example shown in Figures 4A through 4G 
illustrates the steps of navigating an Infomnation service 
web site that generally provides hierarchic layers of In- 
formation. To obtain pertinent information, the naviga- 
tion process has to go through all the nodes on the way 
to the destined page. It Is understood that the final page, 
I.e. the weather information in Town A is what the user 
Is interested in. Thus, in many systems, a user would 
need to labouriously navigate through hierarchies to ob- 
tain the final information. However, the present invention 
contemplates a system wherein the user does not have 
to view Intermediate pages and enter Intermediate re- 
quests sequentially that cause further intermediate pag- 
es to arrive in order to eventually get to a final page. 
Specifically, the present invention introduces a system 
wherein compound requests may be entered such that 
intermediate pages may be skipped in order to reach 
the destined page directly. 

[0042] Figures 6A to 6C illustrate an example of quick- 
ly fetching a final page using compound requests. The 
example of Figures 6A to 6C parallels the example In 
Figures 4A to 4G to demonstrate a compound request 
comprising a plurality of individual requests. Specifical- 
ly, instead of entering one selection or request in a 
choice card, a user can enter a sequence of requests. 
Figure 6 A replicates Figure 4A for clarity and Figure 6B 
shows the screen display 308 interpreted from a choice 
card after the user presses the soft key "OK* 306. As 
described above, the user may either choose an item 
by moving the arrow 310 downward or press one or 
more numbered keys with the first one corresponding to 
a choice item in the choice card screen display 308. To 
be more specific, the first numbered key pressed must 
correspond to one of the items in the display screen in- 
cluding those items in the next screen if the multiscreen 
indicator 312 is displayed. If the first request does not 
correspond to the item In the display screen, for example 
"9" being entered while there are less than 9 items in 
the display screen, the client module 146 in the mobile 
device 1 42 would be caused to look for a card that is not 
in existence In the deck received from the server device 
144. It can be appreciated that there are preferably no 
more than nine items per display screen as the numerals 
■1" to '9". each corresponding to one Item and "O" is 
resented for the equivalence of the "Home" soft key 
[0043] To conform to the example in Figures 4A to 4G 
for clarity, a compound request "2231" is entered 
through the numbered keys in the keypad and echoed 
in the designated window 330 wherein "2" is the first re- 
quest and thus must correspond to one item being in the 
display screen. The subsequent numerals "2" and "3" 
are the intermediate requests, each corresponding to an 
item In subsequent pages. "1" is the final request that 
also corresponds to an item in the last intermediate page 
and leads to the final page showing pertinent informa- 
tion in interest. 

[0044] Upon pressing the "OK" soft key 306. the client 



module 146 examines if the request just entered is a 
compound request. As indicated above, a compound re- 
quest is always more than one digit, proceeding with an 
antecedent request and following by a final request 
s wherein the antecedent request may comprise a plural- 
ity of individual requests or intermediate requests. If the 
received request has one digit, the client module 146 
processes the request as usual to activate a card that 
corresponds to the digit. If the client module 146 finds 

10 the received request has more than one digits, a parsing 
process is activated to parse the compound request into 
indivkfual requests, each is respectively and sequential- 
ly processed as It was entered individually. It is under- 
stood to those skilled in the art that parsing the com- 

is pound request can be readily implemented and embed- 
ded in the client module 146.' However, the request 
could also be transmitted to the server and parsed by 
the server module. Figure 6C shows that the final page 
having the pertinent information has been obtained by 

20 the compound request. 

[0045] Two embodiments of a compound request 
processing have been investigated. Figure 8 illustrates 
the compound request being processed by the client 
module 146 using a first embodiment and should be un- 

2S derstood in conjunction with Figures 4A to 4G, Figures 
6Ato6Cand Figure 7. The client module 146 processes 
the request using a deck received in the mobile device 
1 42 as illustrated in Figure 7. After the client nrKXiule 1 46 
parses the compound request "2231 ' Into "2", "2", "3" 

30 and "1 ". each request is executed as if individually and 
successively entered in the embodiment of Figure 8. 
The first "2" in the compound request is a request from 
the user to access the XYZ information Web in order to 
fetch the weather information in Town A. Referenced by 

35 450 in Figure 7. the deck is received accordingly from 
the server device 144 that hosts the XYZ information 
Web service in response to the first "2". Upon receiving 
the deck in the cache and activating the first display card 
452, the following or intermediate request "2" is proc- 

40 essed and causes a card transition from Card 1 to Card 
k, namely the client module 146 activates the corre- 
sponding card 454 (Card k) in the deck 450, which has 
the screen display in Figure 4E. This card Is displayed 
for a few seconds. The second immediate request "3" 

4S causes another card transition from Card k to Card 3, 
namely the client module 146 activates the correspond- 
ing card 456 (Card k) in the deck 450. which has the 
screen display in Figure 4F Thus, card 456 is displayed 
for a few seconds. The last request "1 " further causes 

so still another transition from Card 3 to Card N, namely 
the client module 146 activates the corresponding card 
456 (Card N) in the deck 450, which has the screen dis- 
play of Figure 4G. It is additionally noted that cards 452, 
454 and 456 are hypertext having linkages to other 

55 cards in the deck. 

[0046] Figure 8 shows a functional flowchart 500 that 
represents the processes and steps in the disclosed in- 
vention. At step 502, a card, typically a choice card, is 
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received in the client device. It can be appreciated by 
now that either a card or a deck containing the card may 
have been received from a server device depending on 
what the client device is. If the client device is, for ex- 
ample, the mobile phone 120 in Figure 2 that has a 
memory (cache) of sufficient capacity capable of receiv- 
ing one or more decks, the server device normally sends 
multiple cards or decks so as to allow the client device 
to navigate the hypertext cards within the received deck 
or decks. The communication between a client device 
and a server device in the form of decks is referred to 
as the cache case hereinafter. If the client device does 
not have sufficient memory (cache) to receive a deck, 
the server device can send an individual card, which 
means a communication request is initiated ever time a 
card transition takes place in the client device. The com- 
munication between a client device and a server device 
in the form of one card is referred to as the cacheless 
case hereinafter. 

[0047] Upon receiving the display card, the client 
module interprets it and causes it to be displayed at 504, 
which is typically a list of items with a designated display 
window to echo a request entered by the user via the 
keypad. At 506, a request is entered, i.e. one or more 
numerals are keyed in by depressing corresponding 
numbered buttons in the keypad and the numerals are 
displayed in the designated windowforthe userto sense 
the entry. At 508. the entered request is examined by 
the client module to determine if it is compound request. 
If the entered request Is a single numeral, the request 
is processed as usual to activate a card that responds 
to the numeral. In the cache case, the card may be one 
of the cards in the deck received in the cache, resulting 
in a short response time to display the activated card. 
In the cacheless case, a connection to the server device 
is made to fetch a card, for example, from the HDML 
decks 154 in the server device 144 in Figure 3. If the 
entered request is a compound request, a parsing proc- 
ess is activated to parse the compound request into in- 
dividual requests, each is sequentially and respectively 
processed. In either case, a corresponding card is acti- 
vated per each request at 512. As illustrated in Figures 
4A to 4G. all the intermediate pages are displayed se- 
quentially at 516 according to the compound request. 
When the final request is processed, the corresponding 
card containing desired information is displayed at 514. 
In the cacheless case, the client device sends the en- 
tered request, regardless of the types thereof, to the 
server device that has a similar parsing process to parse 
the compound request into individual requests. To min- 
imize the air traffic and increase the response time, each 
of the individual requests is sequentially processed, 
fetching respective cards until the final request. When 
the final request is processed, a card corresponding to 
the final request is fetched from a linkage in the last in- 
termediate card and the corresponding final card is then 
sent back to the client device for display, hence a user 
sees a desired display after a compound request is en- 



tered and activated. 

[0048] Figure 9 shows a flow diagram of an alternate 
method of processing compound requests. At step 902, 
a card, typically a choice card, is received in the client 
s device. It can be appreciated by now that either a card 
or a deck containing the card may have been received 
from a server device depending on what the client de- 
vice is. Upon receiving the display card, the client mod- 
ule interprets it and causes it to be displayed at 904. 
10 which is typically a list of items with a designated display 
window to echo a request entered by the user via the 
keypad. At 906, a request is entered, i.e. one or more 
numerals are keyed in by depressing corresponding 
numbered buttons in the keypad. At step 908, the en- 
15 tered request is examined by the client module to deter- 
mine if the request is a compound request. If the entered 
request is a single numeral, the request is processed as 
usual to fetch a card that corresponds to the numeral at 
step 918. If the entered request is a compound request, 
a parsing process is activated to parse the compound 
request into individual requests, each is sequentially 
and respectively processed. Specifically, a correspond- 
ing card is fetched per each intermediate request at step 
912. In this second embodiment, no intermediate cards 
are displayed. When the final request is processed, the 
corresponding card containing desired information is 
displayed at 914. 

[0049] The present invention has been described in 
sufficient detail with a certain degree of particularity. It 
is understood to those skilled in the art that the present 
disclosure of embodiments has been made by way of 
example only and that numerous changes in the ar- 
rangement and combination of parts as well as steps 
may be resorted without departing from the spirit and 
scope of the invention as claimed. Accordingly, the 
scope of the present invention is defined by the append- 
ed claims rather than the forgoing description of one em- 
bodiment. 



Claims 

1 . A method for accelerating navigation of hierarchical 
layers of accessible information hosted in a server 
device through a two-way communk^tion device 
over a data network, the method comprising: 

displaying a menu on a client device, said menu 
comprising a plurality of items, each item hav- 
ing an address identifier; 
receiving a compound request entered by a us- 
er of the two-way communication device to dis- 
play desired information; 
parsing said compound request to obtain an an- 
tecedent request and a final request; 
processing the antecedent request and the final 
request to obtain a final address identifier; and 
displaying desired information kientified by 
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said final address identifier. 

2. The method as recited in claim 1 wherein the ante- 
cedent request comprises at least one intermediate 
request Including a first intermediate request. s 

3. The method as recited in claim 2 wherein the first 
intermediate request corresponds to one of the 
items in the menu. 

10 

4. The method as recited in claim 2 or 3 wherein the 
compound request comprises a sequence of nu- 
merals, a first numeral sequence representing the 
first intermediate request, subsequent numerals 
representing one of the intermediate requests re- is 
spectively and a final numeral in the numeral se- 
quence representing the final request. 

5. The method as recited in any preceding claim 
wherein the menu has no more than 9 items. 20 

6. The method as recited in any preceding claim 
wherein the antecedent request comprises at least 
one intermediate request and wherein the anteced- 
ent request and the final request processing com- 2S 
prises: 

fetching intermediate cards according to the at 
least one intermediate request; and 
fetching, based on the intermediate cards, a fi- 30 
nal card according to the final request. 

7. The method as recited in claim 6 wherein displaying 
a menu comprises displaying a first card, said meth- 
od further comprising: 3S 

displaying said intermediate cards after fetch- 
ing said intermediate cards. 

8. The method as recited in claim 6 or 7 wherein dis- 
playing a menu comprises displaying a first card, 40 
said method further comprising: 

displaying a final card after processing said 
compound request. 

9. The method as recited in any preceding claim fur- 4S 
ther comprising: 

fetching a deck of cards from said server de- 
vice into said client device by the data network, said 
deck of cards comprising a first card corresponding 
to said menu. so 

10. The method as recited in claim 9 further comprising: 

sending the final request across the data net- 
work to the server device; ss 
receiving a final deck having a final card corre- 
sponding to the final request; and 
displaying the final card on the client device. 
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